1. The Field of the Invention
The present invention generally relates to systems and methods for replicating data stores. More specifically, the present invention relates to a protocol for replicating data stores in a sync community.
2. Background and Relevant Art
Background
In today's world of digital information handling, individuals may store information or data in a variety of different devices and locations. Often the user stores the same information in more than one device and/or location. Obviously, the user would like all of the various data stores to have the same information without having to manually input the same changes to each data store. Replication is the process used to ensure that each data store has the same information.
For example, a user may maintain an electronic address book in a myriad of different devices or locations. The user may maintain the address book, for example, on a personal information manager stored on their desktop computer, on their laptop computer, in a personal digital assistant (PDA), in an on-line contacts manager, and the like. The user can modify the electronic address books in each location by, for example, adding a contact, deleting a contact, or changing contact information. One goal of replication is to ensure that the change made on a particular device is ultimately reflected in the data stores of the user's other devices.
Various problems with current replication methods include inefficient use of bandwidth by replicating items that are already replicated but appear to be unreplicated, replication reflection, replication loops where data in one replica is continually updated and replaced, having data that is replicated being perceived as in conflict, and the like.
Further, some methods of replication use synchronous protocols that require handshaking and message acknowledgement. Because these protocols require handshaking and acknowledgement, these protocols normally have a time-out parameter within which acknowledgements should be sent. As a result, the connection between replicating replicas should be active during an entire replication. In addition, some protocols require that changes be sent and received in a certain order. If the changes are sent out of order, changes that are chronologically less current may be used to replace more current items.
Current protocols may also require the replicas to suspend other operations until changes are received and applies. This is done because changes must be applied in the order that they are made. If other operations are not suspended, changes may be made that would then be replaced by chronologically less current changes. Current protocols also suffer from problems when changes are sent by one replica and not received by another. In some cases, the a replication anchor may be updated by the sending replica such that the sending replica believes that changes have been received by another replica when in fact they have not.
In a replicated system, simply ensuring that every replica in a sync community sees every action or change is not sufficient to ensure eventual consistency among the replicas in the sync community. The replicas should apply changes in a consistent order, resolve conflicts in a consistent manner.